home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1181 < prev    next >
Internet Message Format  |  1994-08-27  |  5KB
  1. Date: Sat, 30 Jul 94 01:02 CDT
  2. From: ekl@sdf.lonestar.org (Evan K. Langlois)
  3. To: gem-list@world.std.com
  4. Subject: Re:  Digested
  5. Precedence: bulk
  6.  
  7. ========================================================================
  8. num        Decimal number in ascii, 0xHexadecimal number
  9. geometry   [ Width "x" Height ] [ "+" Xoffset "+" Yoffset ] - all in decimal.
  10. file       Filename in ascii, extension gives clue to type.  (full path only?)
  11. font       <fontname>@<fontsize>
  12. ========================================================================
  13.  
  14. Hmm .. Here's a nifty trick that is better than geometry settings.
  15. Use shel_get() to read the desktop inf file and place your windows
  16. where the desktop does.  Now, since you don't want to put windows
  17. on TOP of each other for different apps, use the window handle
  18. as an index (can we assume that window handles are always allocated
  19. sequentially?)  Then you can set the position and size of every window
  20. on your system and save desktop.  Only problem is that the desktop itself
  21. won't index properly and some windows will be stacked on top of each
  22. other.   But, its an idea.  Geometry limits everything to a set size
  23. and position relative to the last window (or 0) so windows still stack.
  24. You could still use shel_get and forget using window handles as a
  25. index, and just stack the application windows on top of the desktop's.
  26.  
  27. Hmm .. I don't think a full path is needed.  Applications shouldn't
  28. change from the working directory so making things relative to that
  29. shouldn't be too hard.  For global settings you either use the full
  30. path, or if you want to access a different file for each application
  31. with one global setting, then make it relative.
  32.  
  33. Why anyone would do such a thing is beyond me.
  34.  
  35. Are font sizes in points or pixels?  Anyone have any good code to
  36. convert between the two?   Say, if I have a 10 point font, and I
  37. want to scale it to 11 point, how many pixels is that?  NVDI scales
  38. fonts based on pixel size, and I think Speedo does too (not sure).
  39.  
  40. ========================================================================
  41. <application-name>.<attribute-name>.<attribute-type>
  42. myWord.helpDialog.confirm.key: Return   (attribute-name = helpDialog.confirm)
  43. ========================================================================
  44.  
  45. Looks fine to me.  Does the code you posted (it was you right, Warwick?)
  46. handle the dot in the center of the attribute properly?  I mean what
  47. happens with :
  48.  
  49. myWord.Help.key: Help
  50. myWord.Help.confirm.key: Return
  51. myword.Help.font.font:            (attribute name of help.font)
  52.  
  53. Will it take myWord.Help.font.font to be the same as myWord.Help.font
  54. and more importantly, SHOULD it?
  55.  
  56. ========================================================================
  57. useful if they use your app with a program for which window redraws are
  58. expensive (eg.  some DTP programs).  It needs to be configurable so
  59. ========================================================================
  60.  
  61. Calligrapher!   Very expensive redraws!   And it redraws the entire
  62. window twice after every dialog.  I guess the programmer doesn't
  63. know about clipping those rectangles and waiting for redraw messages.
  64.  
  65. ========================================================================
  66. The correct way to track every mouse movement is to watch a 1x1 pixel
  67. rectangle.  This is documented in many places.  (example uses are drawing
  68. programs and real-time drags)
  69. ========================================================================
  70.  
  71. I like a snapped 8x8 rectangle.  Less events, faster drawing (usually)
  72. and your icons can be snapped into place by hand instead of using a
  73. special function.
  74.  
  75. ========================================================================
  76. ]If the button is no longer pressed when you process the message, top the
  77. ]window.  This means that the button was tapped on the window with the intent
  78. ]to bring it to the front.
  79.  
  80. Anything like that depends on how fast your machine is.
  81. ========================================================================
  82.  
  83. Technically yes, but if its done RIGHT after the evnt_multi then it
  84. should be OK.  I don't think the code I posted is gonna vary at all
  85. between machines even if you are VERY hard pressed for CPU.  After
  86. all, evnt_multi returns after a sleep, and if you use the MiNT scheduling
  87. (assuming MultiTOS) then you have 2 time-slices, which is either 10ms
  88. or 2 vblanks, I can't remember, I'm tired, let's say a significant
  89. amount of time to complete the graf_mkstate call.
  90.  
  91. However, I don't like press to click for background windows.  If its
  92. faster to top the window than to wait for the click delay, then I
  93. really don't like it.  And I think it gives a false security, making
  94. it even MORE dangerous than simply allowing selection when the object
  95. is fully visible.
  96.  
  97.  
  98.  
  99.